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ABSTRACT: 



A method of scheduling data packets in a multiplexer, particularly in an MPEG-2 server, the 
method comprising the steps of combining a number of packet flows to provide a smaller number 
of flow queues, and operating a scheduling algorithm on the flow queues to select a packet to be 
output. The method may also include the step of generating tokens representing the packets and 
the flow queues may then contain the tokens and not the pacRStsr 
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(54) Multiplexer 

(57) A method of scheduling data packets in a mul- 
tiplexer, particularly in an MPEG-2 server, the method 
comprising the steps of combining a number of packet 
flows to provide a smaller number of flow queues, and 
operating a scheduling algorithm on the flow queues to 



select a packet to be output. The method may also 
include the step of generating tokens representing the 
packets and the flow queues may then contain the 
tokens and not the packets. 
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Description 

[0001] This invention relates to the field of muliplexers and, more particularly, to a method and apparatus for imple- 
menting a scheduling algorithm in a multiplexer. 
5 [0002] Scheduling algorithms are used in multiplexers to manage data flow. There are problems inherent in conven- 
tional scheduling algorithms and also problems associated with their implementation. This invention is concerned with 
the reduction or elimination of such problems. 

[0003] For example, a group of scheduling algorithms known as packet fair queuing algorithms (PFQ) seek to allocate 
multiplexer output fairly to incoming data packet flows. Fairness is described as the maximum difference between the 
10 normalised service received by two bacWogged flows over an interval in which both are continuously bacWogged. Fair- 
ness is desirable so that one packet flow does not receive service in preference to others over the long term. However, 
PFQ algorithms are generally complex. 

[0004] Flow isolation is desirable in order to prevent flows from being adversely affected by individual corrupt packet 
flows, as this improves multiplexer, and hence network, reliability. It is also desirable to keep delay jitter, which is the 
is maximum difference in delays experienced by any two packets in the same flow, to a minimum. Inevitably, algorithms 
which achieve flow isolation and reduce delay jitter are also complex. 

[0005] However, for a scheduling algorithm to be implemented in either software running on a microprocessor or 
directly in hardware Hs complexity must be limited in order that calculations can be carried out at a rate sufficient to keep 
up with network traffic. Furthermore, the use of large memory caches and multiple buffers should be limited in order to 
20 minimise system cost and complexity. 

[0006] The object of the present invention is to provide efficient, reliable and cost effective implementation of sched- 
uling algorithms having desirable charcteristics. 

[0007] According to the present invention there is provided a method of scheduling data packets comprising the steps 

of: 

25 

combining a number of packet flows to provide a smaller number of flow queues; and 
operating a scheduling algorithm on the flow queues to select a packet to be output 

[0008] Preferably, the algorithm is a Fair Queuing algorithm. When the method is used for scheduling data packets in 
30 a MPEG-2 network the algorithm is preferably a Starting Potential based Fair Queuing algorithm. 

[0009] Preferably, the method further comprises the step of generating tokens representing the packets and the flow 
queues may then contain the tokens and not the packets. Preferably the tokens comprise a memory address for a 
packet stored in a packet store. 

[0010] Alternatively, the tokens may contain PiD information relating to the packet flows, and the method may then 
35 further comprise the step of mapping the tokens to the packet flows having the corresponding PID. 

[001 1] Any packet flow may be combined with any other packet flow but it is preferable to combine low and high rate 
packet flows such as those for audio and video data. The combined packet flows should preferably contain related data 
in order to minimise problems associated with the loss of flow isolation. 

[001 2] Also according to the present invention there is provided an apparatus for scheduling data packets comprising: 

40 

mapping means for combining a number of packet flows to provide a smaller number of flow queues; and 
controller means for operating a scheduling algorithm on the flow queues to select a packet to be output. 

[001 3] Preferably the apparatus further comprises means for generating tokens representing the packets and the flow 
45 queues may then contain the tokens. Communication between the means for generating tokens and the controller 
means may then be over a channel of lower bandwidth than that required for the packet flows and output. 
[0014] The invention includes a multiplexer, an MPEG-2 server or a network for transmitting data, including the appa- 
ratus for scheduling data packets described above and/or using the method described above. In particular, the invention 
includes an MPEG-2 network including the apparatus for scheduling data packets described above and/or using the 
so method described above. 

[0015] An example of the present invention will now be described with reference to the accompanying diagrams, in 
which: 

Figure 1 is a flow chart for a scheduler implementing the use of tokens; 
55 Figure 2 is an illustration of flow mapping; and 

Figure 3 is a flow chart of a scheduler implementing the use of tokens and flow mapping. 

[001 6] In this example a Starting Potential based Fair Queueing (SPFQ) algorithm is used. This algorithm has desir- 
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able scheduling properties that allow the implementation of, for example, mufti-server MPEG-2 networks, but rt also has 
several complex features difficult to implement in a high speed system. In particular, these include the size of virtual 
time memory(s) required and the complexity of the virtual time reference and packet selection calculations. The com- 
plexity of the calculations is a function of the number of flow queues provided. In an MPEG-2 network this is governed 
5 by the number of packet identifiers (PIDs) which is a maximum of 8192. Each PID forms a separate packet flow (PID 
flow) and hence a separate flow queue. There is therefore a compromise between the number of packet flows sup- 
ported and the packet processing speed of the multiplexer 

[0017] SPFQ is a packet fair queueing (PFQ) algorithm suitable for the MPEG-2 network of the present example 
because of its inherent tight delay bounds, fairness, flow isolation and reasonable computational complexity. It is best 
w implemented in a Field Progammable Gale Array (FPGA) as this provides fast embedded memory and a parallel 
processing architecture which can be made specific to the application. However, it is not possible to operate at the req- 
uisite packet output rate of 100 Mbitss" 1 using conventional implementation techniques. 

[0018] The MPEG-2 systems standard (ISO/IEC 13818-1) specifies a packetised transport stream as the communi- 
cation medium to convey compressed video, audio and associated service information from source to destination. The 
is transport stream is conveyed over an MPEG-2 packet network which comprises of one or more MPEG-2 servers. A 
multiplexer implemented in a MPEG-2 server orders incoming packet flows onto a common output link. For the pur- 
poses of describing MPEG-2 packet scheduling the network layers below the MPEG-2 packet transport stream are not 
considered. 

[001 9] PFQ algorithms allocate each packet flow a share of the available multiplexer bandwidth. Packets to be sched- 
20 uled are given a time stamp relative to a virtual time generated by the algorithm. The time stamps are used to order 
packet selection onto the output link. 

[0020] The time stamp of a SPFQ algorithm comprises a virtual start time and a virtual finish time which is allocated 
to all bacWogged packets in the scheduler. The start time, S*^, and finish time, F*^-, derived from the virtual time, Vj are 
defined as 

S^maxlF^.V^)} 

where a*,j is the arrival time of packet k on scheduler flow queue / (=1,2,..M) at multiplexer j (=1,2,..N), and p,j is the 
rate allocated to scheduler flow queue / of multiplexer j. 

[0021 ] The calculation of the finish time can be simplified for the MPEG-2 network as this has fixed length packets, so 

F k -s k +-!=- 
F <J- S 'J% fJ 

40 [0022] It can be appreciated that the start time S*/j is the later (or greater) of the virtual time at the packet arrival and 
the finish time of the previous packet in the same flow queue. The finish time F*^ is simply the start time S\j plus the 
time it takes to remove the packet from the flow queue given the rate pq allocated to the packers queue. It should be 
noted that the sum of allocated rates must not exceed the scheduler resources, ie. 

45 M 



so where Rj is the scheduler output rate of server j. 
[0023] The virtual time function is expressed, 



30 



35 



55 



V^t + r) = max{K > (0+ r, . Ji^^/ 0 }} 



where Vfi)=0 for t<,0 and B f {t) is the set of backlogged scheduler flow queues. 

[0024] Scheduling can be considered as two processes. Firstly, on arrival, packets are stored in a flow queue and their 
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start and finish times are allocated. In order for these times to be allocated, the virtual time must be calculated at the 
time the packet arrives (T=a*y-f). 

[0025] Secondly, the packet with the minimum finish time is selected for output by the scheduler. When the selected 
packet is removed the virtual time is updated using the soonest start time of the start times of the packets in the sched- 
5 uler flow queues. 

[0026] Scheduler flow delay and queue backlog bounds can be described provided a traffic constraint function for the 
traffic flow is known. The preferred model for determining a traffic constraint function is known as the leaky bucket" 
model, in which the flow delay D is expressed as 

D u=—+®u 



15 



MAX 



where is the burstiness of the flow prior to the scheduler /. It should also be noted that the burstiness rises monot- 
onically at each multiplexer in the network. Also, the scheduler maximum and minimum latency is expressed 

20 

~MAX L . L 
~MIN L 

[0027] Delay jitter, DJ, is expressed as 

30 N 



<7 

35 DJ { 



'I k'1 



[0028] In order to reduce the number of start and finish times which must be stored, only start and finish times for 
40 packets at the head of a scheduler flow queue (HoQ), which always have the smallest start and finish time in each 
queue, are stored. In other words, as the HoQ packets are always scheduled before any other packet in the same 
queue, only HoQ packet finish times are required by the scheduler to make a scheduling decision. Similarly only HoQ 
start times are required to update the virtual time reference. 

[0029] Conveniently, when a packet is selected and removed from a queue and the queue is still backtogged, the new 
45 HoQ packet will have a start time equal to the previous packet's finish time as the algorithm will always service a packet 
before the virtual time reference is greater than that packet's finish time. However, when a packet arrives onto an empty 
queue a full calculation is required as the packet may arrive before or after the finish time of the last packet. Hence the 
HoQ start and finish time functions may be defined as 

so S u ia^hwax[F u {a^). Vjtfj-)) if q y (a* -)=0 



where S,j[t)=0 and F f j(t)=0 for t ZO, t- is the instant before f, and / is any packet arrival time, or packet removal 
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time, f. 

[0030] For simplicity, the full calculation may be used to compute Sy when a packet is removed. 
[0031 ] The set of backlogged HoQ start and finish times may be written 

10 

[0032] Referring to Rgure 1, a flow queue controller 1 maintains the flow queues and acts as a HoQ change fitter 
outputting a scheduler flow queue signal F when the HoQ packet in queue / changes. A virtual time processor (VTP) 2 
receives the scheduler flow queue signals P and updates the start and finish times when a HoQ change occurs. Only 
is one HoQ change event can occur per scheduler flow queue per output packet selection. The Virtual time reference con- 
troller 22 updates the virtual time. 

[0033] Row selection is carried out by flow selector 21 , which outputs selection signal f indicating the selected flow 
queue to the flow queue controller 1 . The flow queue controller then initiates removal of the respective packet from the 
head of the selected flow queue, h r . Packet removal causes a HoQ change event and the HoQ start, finish and virtual 
20 time reference are again updated as necessary. It can be appreciated that multiple flow queue controllers may be used. 
[0034] tt can be appreciated that packet storage and removal in flow queues, determining a HoQ change, updating 
start and finish times, finding the minimum start and finish time, and timing the period between the last virtual time 
update to a packet arrival or packet selection event all take a finite time to complete. Thus, the data must be held con- 
stant while the calculations are performed. This is achieved by packet store 3, shown in Figure 1 , in which packet arriv- 
es als k are queued until a release time which occurs periodically. 

[0035] It can be appreciated that as packet arrival times are delayed by the packet store 3. the resultant start, finish 
and reference times, and hence packet order, will be different to that of the theoretical case considered above, in which 
no account is taken of delays caused by hardware. 

[0036] The interval between release times may conveniently be chosen as the same as the output packet period 
30 x=URj. x is a constant so there is no need to measure packet arrival times precisely. As the scheduler is busy transmit- 
ting the outgoing packet during t the packet store 3 does not cause an overall increase in the delay suffered by any 
packet flow provided the interval between release times is less than or equal to the output packet period x. 
[0037] It is important that the flow queue controller 1 and VTP 2 process incoming packets from the store 3 in time to 
allow for packet selection and virtual time calculation. This must all be done during the time it takes to output a selected 
35 packet 

[0038] In order to improve processing speed, a token is used to indicate the packet arrival. Tokens may be used as 
packet contents are not actually required by the scheduler. In the present example the packet store 3 provides the 
tokens representing packets arriving at the store. 

[0039] Each token uniquely identifies a packet and the tokens and not the packets are stored in the flow queues. Then 
40 a flow queue is selected by flow selector 21 , flow queue controller 1 passes a token relating to the head of queue packet 
in the selected flow queue to token controller 4. The token controller 4 then identifies the packet in the packet store 3 
which corresponds to the token, and the packet is output, in turn, from the packet store 3. 

[0040] In this example, a token is a memory location for a corresponding packet in the packet store 3 and the token 
controller 4 simply addresses the packet store 3. However, where there are multiple packet stores 3 the token may also 
45 include a packet store identification information. Alternatively, the token may contain the packet PID and the token con- 
troller uses a token map to identify the packet store memory location for the given the PID. Conveniently, tokens may 
contain PIDs remapped as they are required to appear in the output transport stream. 

[0041 ] If multiple packet stores 3 are used, as is often the case, the packet store token output should be ordered so 
that the flow queue controller 1 does not receive simultaneous token arrivals. This may be achieved by using an arbiter 
so to control delivery of tokens from the multiple packet stores. This is not the only way in which tokens may be ordered 
into the flow queue controller 1, but is advantageous in that tokens from any store can be mapped to any flow queue 
and a standard multi-drop bus can be used to convey the tokens. 

[0042] It is difficult to implement an SPFQ algorithm in present hardware such that it operates with sufficient speed 
and, in particular, with sufficient speed to operate in an MPEG-2 network. Conventional implementation of PFQ algo- 
55 rithms has generally required reduction in the complexity of the algorithm which causes a corresponding reduction in 
the desirable characteristics of fairness, isolation and delay bound. 

[0043] The use of tokens is advantageous in that it reduces the amount of data transferred to the flow queue controller 
1 and reduces flow queue storage requirements, both of which reduce implementation complexity without compromis- 
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ing performance. Also, the scheduling algorithm can be changed or modified without changing the packet store 3. 
[0044] It should be noted that plural VTPs 2 may be used in parallel, all linked to a single flow queue controller 1 . Each 
VTP 2 is allocated a number of flow queues and the flow selector 21 selects a flow queue from the results of all the 
VTPs 2. 

5 [0045] In order to improve the possibility of effective implementation without reducing algorithm complexity, the 
number of packet flows operated upon can be reduced or the speed of the search function of the flow selector 21 which 
selects the minimum finish time F*)j can be improved. It is, of course, undesirable to reduce the number of packet flows 
operated upon, as this inevitably reduces the amount of data the multiplexer can handle. 

[0046] Schemes to improve search function speed, such as those using tree structures or more advanced structures 
w like the stratified trees are complex and difficult to implement in hardware. In this example a linear minimum search 
scheme is employed. 

[0047] However, even rf the linear minimum search is fast, it is unlikely that calculation speed will be improved suffi- 
ciently for the multiplexer of the present example to operate in an MPEG-2 network. A technique called flow mapping is 
therefore employed to reduce the number of scheduler flow queues. Flow mapping involves the mapping of packets 

15 from one or more input packet flows to the same scheduler flow queue. 

[0048] Referring to Figure 2, in an MPEG-2 network, flow mapping allows different PID flows to share the same sched- 
uler flow queue. It is required that each packet flow must map to only one scheduler flow, although many input packet 
flows can be mapped to the same scheduler flow queue. A flow map controller 5 is therefore provided between packet 
store 3 and flow queue controller 1. The flow map controller 5 of the present example comprises a PID de-multiplexer 

20 51 for mapping the packet into flow queues (illustratively shown as 52 in Figure 2). 

[0049] Flow mapping is advantageous in that it allows a realistic number of scheduler flow queues to be provided with- 
out restricting the number of schedulable PIDs (ie. packet flows). It also allows the delay bound of an individual input 
PID flow to be reduced and allows statistically multiplexed PID flows, that have a constant group rate, to be efficiently 
multiplexed. 

25 [0050] It must, however, be noted that, by grouping packet flows into one scheduler flow queue the isolation between 
the packet flows is lost. Thus, if a packet flow becomes corrupt it will affect the delay and packet loss suffered by other 
packet flows sharing the same scheduler flow queue. Row mapping must therefore be implemented carefully. For 
example, in an MPEG-2 network, corresponding audio and video packet flows may be grouped together. 
[0051 ] The number of scheduler flow queues and how the packets are mapped determines the maximum number of 

30 PID's that can be scheduled. In an MPEG-2 network, a 100 Mbrtss" 1 transport stream may contain 50 video/audio serv- 
ices and a similar number of information data streams. With the packet flows corresponding to the same service 
mapped to the same scheduler flow queue, the number of flow queues provided by a basic scheduler should be 100 to 
200 flow queues. In other words, if each service has around 4 to 8 PIDs around 400-1600 PIDs can be scheduled. 
[0052] With flow mapping a scheduler flow queue comprises many packet flows so for leaky bucket modelled streams 

35 the new constraint function, A'y, is expressed as 

9*Gij 9*Gij 

40 

where g is the index of packet flows and Gjj is the set of packet flows mapped to scheduler flow queue / at scheduler j. 
[0053] The delay for a scheduler flow queue is now expressed as 



45 



50 



Z "an 
J * r g f>u r j 



[0054] The allocated rate, should be greater than or equal to the sum of the rates of input flows mapped to sched- 
uler flow /'. 

[0055] As the allocated rate, p/j. for the scheduler flow / is going to be higher than the rate of the packet flow, r g , then 
we notice a key feature of flow mapping, namely that the delay, backlog and jitter bounds of a packet flow can be 
55 reduced when it is grouped with other packet flows. It is easy to show that D a+b j^D a j and hence DJ^^DJ^ when the 
following condition exists, 
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s [0056] Audio flows are low in rate so the number of remurtiplex stages before the jitter limits specified by MPEG-2 are 
violated is low. One way to reduce the delay bound and hence packet jitter is to over allocate scheduler rate to audio 
flows. However this reduces output utilisation. The alternative provided by flow mapping is to map audio flows to the 
same queue as a high rate flow. In MPEG-2 transport streams a suitable high rate flow is the associated CBR video 
flow. As the video rate is significantly higher than the audio rate, without significantly different burstiness, there is a sig- 

10 nrf icant reduction in delay bound for the audio component allowing the flow to traverse more remurtiplex stages, ft can 
be appreciated that if an audio flow is associated with the video flow at every multiplexer in a network this advantage 
will be optimised. 

[0057] Considering, fa example, a 192Kbrtss 1 audio flow, the minimum receiver multiplex buffer, hence allowable 
delay jitter for audio flows, is 736 bytes or 4 packets. Given a source burstiness of one packet and at each stage the flow 
15 is allocated a rate equal to the long term arrival rate then three remurtiplex stages are possible- However if the audio 
flow were mapped in with a 1 Mbitss' 1 video flow then 8 remurtiplex stages are possible. 

[0058] For the implementation, a way of mapping packet flow indices, g. to scheduler flow queue indices / is required. 
As described above, the packet store 3 produces tokens which provide unique identification of packets in the packet 
store 3, and a token to scheduler flow queue map is also provided. If the tokens contain packet PIDs then the map is 
20 conveniently a PID to scheduler flow queue index map. It should, however, be noted that if the token is just a memory 
location this map would be more complex. Including the packet PID in the token allows the PID to flow queue mapping 
process to be performed with the token from the packet store 3 as shown in Figure 3. 

[0059] The flow map controller 5 outputs the token so it can be stored by the flow queue controller 1 in a scheduler 
flow queue /. Advantageously, a shared bus may support multiple packet stores 3 provided a token to flow queue map 
25 is provided for each flow queue controller 1 . However, as the PID to packet flow association is fairly static the flow map- 
ping function could be integrated with the packet store 3 to remove the need for a flow map controller and scheduler 
flow queue information included with the token. 

[0060] Flow mapping also allows the multiplexing of statistically controlled f tows to be implemented effectively. 
[0061 ] Statistically controlled flows are rate controlled flows arranged into groups by a controller so that the total group 

30 bit rate is constant. The members of the group have their rate adjusted to maintain constant data quality. Each flow 
therefore has a pseudo-variable rate with a maximum bit rate approaching the group maximum. 
[0062] A problem encountered when implementing a multiplexer handling statistically controlled flows is that traffic 
flow models, such as the leaky bucket model described above, require a long term packet flow rate parameter for each 
packet flow to estimate delay bounds. However, as described above, although the statistically controlled flow has a 

35 more or less continuous rate, each individual packet flow of the statistically controlled flow has a continuously varying 
rate. Row mapping according to the present invention allows all the packet flows of a statistically controlled flow to be 
grouped to one scheduler flow queue, and thus only the more or less continuous rate of the group needs to be consid- 
ered to estimate the delay bound. Also, as flow mapping is used the individual packet flows will have lower delay bounds 
than if they were treated individually (see above). 

40 [0063] Finally, it is desirable to separate the packet store 3 and the other incoming packet flow functions from the cal- 
culation functions of VTP 2, flow controller 1 , flow selector 21 and virtual time reference controller 22. The use of tokens 
between the packet store and flow queue controller 1 minimises the bandwidth of the channel between these two sec- 
tions of the scheduler and this channel can thus be a propriety or standard bus interface such as PCI. 

45 Claims 

1 . A method of scheduling data packets comprising the steps of: 

combining a number of packet flows to provide a smaller number of flow queues; and 
so operating a scheduling algorithm on the flow queues to select a packet to be output. 

2. The method of claim 1 , wherein the step of operating a scheduling algorithm comprises operating a Fair Queuing 
algorithm. 

55 3. The method of claim 2, wherein the step of operating a Fair Queuing algorithm comprises operating a Starting 
Potential based Fair Queuing algorithm. 

4. The method of any of claims 1 to 3, further comprising the step of generating tokens representing the packets and 
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wherein the flow queues contain the tokens. 

5. The method of claim 4, wherein the step of generating tokens comprises generating tokens which comprise a mem- 
ory address for a packet stored in a packet store. 

5 

6. The method of claim 4, wherein the step of generating tokens comprises generating tokens comprising PID infor- 
mation relating to the packet flows. 

7. The method of claim 6, further comprising the step of mapping the tokens to the packet flows having the corre- 
10 sponding PID. 

8. The method of any of the preceding claims, wherein the step of combining a number of packet flows comprises 
combining a low rate packet flow with a high rate packet flow to form a flow queue. 

is 9. The method of any of the preceding claims, wherein the step of combining a number of packet flows comprises 
confining packet flows of related data to provide a flow queue of related data. 

10. The method of claim 8 or 9, wherein the step of combining packet flows comprises combining one packet flow of 
audio data and another packet flow of corresponding video data. 

20 

1 1 . An apparatus fa scheduling data packets comprising: 

mapping means for combining a number of packet flows to provide a smaller number of flow queues; and 
controller means for operating a scheduling algorithm on the flow queues to select a packet to be output. 

25 

12. The apparatus of claim 1 1 , wherein the algorithm is a Fair Queuing algorithm. 

13. The apparatus of claim 12, wherein the algorithm is a Starting Potential based Fair Queuing algorithm. 

30 14. The apparatus of any of claims 1 1 to 1 3, further comprising means for generating tokens representing the packets 
and wherein the flow queues contain the tokens. 

1 5. The apparatus of claim 1 4, wherein the mapping means and controller means are connected by a channel of lower 
bandwidth than the channel required for the packet flow and output. 

35 

16. The apparatus of claims 14 or 15, wherein the tokens comprise a memory address for a packet stored in a packet 
store. 

17. The apparatus of claims 14 or 15, wherein the tokens contain PID information relating to the packet flows. 

40 

18. The apparatus of claim 1 7, further comprising means for mapping the tokens to the packet flows having the corre- 
sponding PID. 

1 9. The apparatus of any of claims 1 1 to 18, further comprising means for combining a low rate packet flow with a high 
45 rate packet flow to form a flow queue. 

20. The apparatus of any of claims 1 1 to 1 9, wherein data carried by packet flows of a flow queue is related. 

21. The apparatus of claim 19 or 20, wherein one packet flow is for audio data and another packet flows is for corre- 
50 sponding video data. 

22. A multiplexer including the apparatus of any of claims 1 1 to 21 . 

23. An MPEG-2 server including the apparatus of any of claims 1 1 to 21 . 

55 

24. A network for transmitting data including the apparatus of any of claims 1 1 to 21 . 

25. An MPEG-2 network including the apparatus of any of claims 1 1 to 21 . 
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